Secure data communications systems are used to transfer information between a pair of correspondents. At least part of the information that is exchanged is enciphered by a predetermined mathematical operation by the sender. The recipient may then perform a complimentary mathematical operation to decipher the information. For public key or symmetric key systems, there are certain parameters that must be known beforehand between the correspondents. For example, various schemes and protocols have been devised to validate the senders public key, the identity of the sender and the like. The security or validity of these systems is dependent on whether the signature is a valid signature and this is only the case if system parameters if any are valid, the public key is valid and the signature verifies. Furthermore, an asymmetric system is secure only if system parameters if any are valid, the enciphering public key is valid, the symmetric key is formatted as specified and the symmetric key recovery checks for format validity.
On the other hand a key agreement protocol is secure only if the system parameters, if any, are valid, the key agreement public keys are valid, and the shared secret and symmetric key is derived as specified in a standard. In all of these it is assumed that the public key or symmetric key, i.e. the shared secret, is derived and valid as specified in the protocol scheme. Problems, however, will arise if these parameters are either bogus or defective in some way.
The following scenarios may illustrate the implications of a defect in one or more parameters of a public key cryptographic system. For example digital signatures are used to indicate the authenticity of a sender. Thus if a Recipient A receives a certified public key from a Sender B, then A verifies the certificate, next B sends A a signed message for which A is able to verify the signature and thus assume that further communication is acceptable. In this scenario, however, if B has deliberately corrupted the public key then the Recipient A has no way of distinguishing this invalid public key. Similarly, a Participant C generates a key pair and then subsequently receives a public key certificate, the Participant C then sends the certificate and a subsequent signed message to B under the assumption that the public key contained in the certificate is valid. The participant B can then determine key information for C. Both the above scenarios describe possible problems arising from utilizing unauthenticated parameters in signature verification.
In key transport protocols a Correspondent A may inadvertently send its symmetric key to the wrong party. For example, if Correspondent A receives a certified public key from a Sender B, the certificate is verified by A who then sends a public key enciphered symmetric key and a symmetric key enciphered message to B, thus A is compromised. Conversely, if one of the correspondents C generates a key pair and gets a public key certificate which is subsequently sent to A who public key enciphers a symmetric key and message and sends it back to C, thus, in this case, C is compromised.
In key agreement protocols, one of the correspondents, A for example, receives a certified public key from B and sends B A's certified public key. Each of A and B verify the other's certificate and agree upon a symmetric key. In this scenario A is compromised twice.
It may be seen from the above scenarios that although public key systems are secure the security of the system relies to a large extent on one or both of the correspondents relying on the fact that a claimed given key is in fact the given key for the particular algorithm being used. Typically the recipients receive a string of bits and then make the assumption that this string of bits really represents a key as claimed. This is particularly a problem for a symmetric key system where typically any bit string of the right size may be interpreted as a key. If a bit in the key is flipped, it may still be interpreted as a key, and may still produce a valid crypto operation except that it is the wrong key.
In an asymmetric private key system the owner of the private key knows everything about the private key and hence can validate the private key for correctness. However, should a third party send the owner system a public key, a question arises as to whether the received key conforms to the arithmetic requirements for a public key or the operations using the claimed public key is a secure crypto operation. Unless the owner system performs a check it is unlikely to know for certain and then only by the owner.
From the above it may be seen that key establishment may be insecure. In a paper written by Lim and Lee presented at Crypto '97, this problem was demonstrated in context of the Diffie-Hellman scheme using a bogus public key that did not have the correct order and thus one party was able to find information about the other party's private key. In the RSA or Rabin scheme, which gets its security from the difficulty of factoring large numbers, the public and private keys are functions of a pair of large prime numbers. The keys are generated from the product of two random large prime numbers. Suppose, however, that n is a prime instead of the products of two primes then phi(n)=n−1 so anyone can determine d from the bogus “public key” (n,e). These are just examples of the problems a user of a public key can get into if they cannot validate the arithmetic properties of a claimed public key for conformance with the requirements of the algorithm.